09. 提交 Commit 最佳做法

正如 Art 所说，提交说明（commit messages）对于解释你为什么要这样修改代码至关重要。它不仅供你的同事或协作者查看，还供你自己将来查看。下面我们来看看编写提交说明的一些最佳做法。

下面是我们在优达学城使用的说明格式。你可以在 这里 找到它以供将来参考。

类型：主题

正文

脚注

第一行是主题。它应该简要说明更改的内容。不建议使用“修复”或“执行了某些操作”这类字眼，主题需要清楚、信息丰富，并努力避免使用亵渎语言。主题不应超过 50 个字符，首字母大写，不以句点结尾。在优达学城，如果提交的类型是错误修复、功能、文档更改等，我们还会包含有关提交类型的简短注释。

接下来是正文，更详细地描述你进行更改的原因。正文每行通常包含 72 个字符左右。这是为了确保在命令行上使用 git 时，提交说明能够在终端窗口中显示出来。你还需要确保主题和正文之间有一个空行。当需要创建列表时，也可以使用星号或短横线添加项目符号。

有些提交的说明中不需要正文。例如，如果更正一个拼写错误，可以只有一个主题行。

还可以包含脚注，这通常用于指示此提交解决哪些问题或错误。

更详实的示例类似下面这样：

功能：用 50 个或更少字符总结改动

如有必要，提供更详细的阐释文本。将其限制在 72 个字符左右。有些情况下，第一行被视为提交的主题，其余文本被视为正文。将摘要与正文分隔开的空行至关重要（除非你完全省略正文）；如果不分隔摘要和正文，“log”、“shortlog”和“rebase”等工具可能不知所措。

解释此次提交要解决的问题。重点是为什么要进行此次改动而不是如何改动（代码会说明这一点）。此次改动是否有任何副作用或其他不太直观的后果？可在此处解释这些方面。

空行后面可以有更多段落。

 - 还可以使用项目符号分项列出

 - 通常使用连字符或星号作为项目符号，前面有一个空格，中间是一些空行，但惯例不尽相同

如果你使用问题跟踪器，请在底部提供对问题的引用，
例如：

解决：# 123
另请参见：# 456、# 789

这也有例外。如果你从事的是一个开源项目，请务必遵守该项目的说明格式。这会让维护者的工作更轻松，并增加你的合并请求被接受的机会。